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Apple's booth shuns Apple II 

Attendees at the national Educational Computing Conference in 
Phoenix, Arizona, report that Apple Computer's exhibit did not sport a 
single Apple 11 computer. Apple's Apple II team told developers such 
as Roger Wagner and Zip Technolo^ that their cohorts in K-12 Educa- 
tion Marketing were responsible for the show and that they had been 
unable to persuade the education people to include Apple II systems. 

This is one of the negative side effects of the consolidation of 
Apple's Apple II champions into the Apple II Business Unit. Having all 
the Apple II people inside Apple's new Consumer Products Division 
frees the other Apple divisions from having to maintain the pretense 
of support. Apparently Apple's head of education marKeting, Bernard 
Qifford, who stood side by side with John ScuUey last year promising 
continued support for the Apple 11, has defined 'support" in a way 
that doesn't include acknowledging that the Apple II continues to 
exist 

Refusing to exhibit Apple II computers at a show where over 60 per 
cent of the computers used in other booths were Apple lis is beyond 
inexcusable. It shows that Apple's education strate^ is to force the 
Macintosh into America's schools even at the risk of huge losses in 
market share, and more importantly, without regard to what It will 
cost the American education system. Apple could be solving the prob- 
lems of today's budget-constrained educators by showing them how 
to add to and enhance the computers already in schools. The Apple 
ligs does what a Macintosh does, but in color, and it also runs the 
software schools already own. But Apple's solution for education is to 
convince administrators that the choice for schools in the 1990s is 
MS-DOS or Macintosh. And taxpayers get saddled with new hardware, 
be it MSDOS or Mac; new software, be It MS-DOS or Mac; and retrain- 
ing millions of teachers — all because Apple's vision isn't big enough 
to include alternatives based on its own computers that are already in 
place in America's schools. 

Hie good news Is that more than K 100 educators took the 
time to attend Roger Wagner's HyperStudio seminar at the con- 
ference. Roger told us that MECC also offered all-day workshops with 
the Ilgs and these were well-attended; he expects the word about the 
intrinsic value of the Ilgs as the multimedia machine of the 1990s to 
be passed along by these participants, if not by Apple itself. 

Apple and IBN are rumored to be discussing a technology 
exchange. A copyrighted article in the June 15th Wall Street Journal 
asserts Apple and IBM may be considering the exchange of powerful 
IBM RISC (Reduced Instruction Set Computer) technology for Apple's 
expertise in designing object-oriented software, possibly representing 
an attempt to provide a technology alternative to Microsoft's MS- 
DOS/Windows environment. Ho announcement has been forthcoming 
as yet.— DJD 

The People vs Programming 

There have been stages in our history where the inability to adopt 
some skills has caused a type of class stratification; most of these 
stages followed a technological revolution where the ability to per- 
form certain actions became a new requirement of daily life. Literacy 
became an increasingly important skill after the invention of the print- 



ing press. The Industrial Revolution altered the structure of society. 

Our current society is undergomg such a change dealing with 
Uie mediums of recording, manipulating, and exchanging infor- 
mation. There have been two related references to this stratification 
in the past month; one a fictionalized accounting, one a real-world 
development. 

One is a scene from the cun-ent movie City Slickers. Two men iso- 
lated from "civilization" on a cattle drive finally have the opportunity 
to discuss the vagaries of VCR use at length; Billy Crystal's character 
is explaining to Daniel Stern's alter ego why it isn't necessary to have 
the television tuned to channel 3 to record. When he explains the 
television doesn't even have to be present to record, the other man is 
aghast. A third character who has been listening to this conversation 
finally explodes, pointing out that some of the cattle no doubt have 
learned to program the VCR at this point, and that further instruction 
is never going to help Stern's character. 

Serendipitously, there was a real-world fallout to this: that very 
month, a new device to "automate" VCR programming appeared on 
the market. The new device is an intelligent remote control called the 
VCR PluSr which can be configured for use with most common cable 
converters, televisions, and videocassette recorders using infrared 
remote controls. The additional feature of the VCR Plus is that when 
you find a program you want to record in the television (or cable) list- 
ings, you look for a multi-digit number next to the listing and enter it 
into the remote. The remote will store the number and, at the appro- 
priate time, start your VCR and record the program. This saves you 
having to learn how to program your VCR to record a show. 

My reaction to the scene in City Slickers is sympathetic to Crystal's 
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character; certainly it isn't unreasonable to patiently try to explain the 
use of technology to someone if they are willing to learn and if you 
have the time and inclination. On a cattle drive, there, isn't much else 
to do; of course, most of us have outside pressures that restrict our 
ability to offer the kind of instruction that Crystal's character tried to 
provide. 

My reaction to the VCR Plus is a little more reactionary because 1 
see it as a step backward. It's easy for me to remember, for example, 
that LA, Law is broadcast from 9 to 10 PM Thursday nights on Chan- 
nel 4 in the Kansas City area. Learning to program that into a VCR 
takes some effort; you have to learn how to enter the information and 
you have to be careful to check that the data is conrect lest you 
record an hour from a "home shopping" station. It gets worse if you 
have multiple VCRs with different programming methods. A single 
device that would allow the consistent, logical entry of the informa- 
tion would be helpful. 

But when you have to look up a number like "7067466/ which 
does not correspond to anything in the way of human-interpretable 
data, have we actually reduced the complexi^ of our lives? You can at 
least remember the time slot for a program; there is no easily discern- 
able rhyme or reason to the VCR Pius numbering system, 

Meanwhile, our local Kansas City Star newspaper reduced the 
information content of the program listings because adding the 4 to 7 
digit VCR Plus numbers after each program entry took up a significant 
amount of space in the listings. So the person who has expended the 
sweat to learn how to program their VCR is now penalized for the 
sake of those who won't. Is this the way technology is going to aid us? 

There is even a phone number that you can call to find out the 
code for a program that isn't listed. All you have to do is provide the 
starting time, ending time, day of the week, and local channel for the 
program and an operator can provide you the number to enter for 
recording. What's amazing is that the individual is still programming 
the VCR; the difference is that the VCR Plus folks get to insert them- 
selves profitably into the process by adding a layer that reduces the 
number of keystrokes you must enter, but totally obscures the mean- 
ing of the information you are entering. 

It isn't that I think the VCR Plus concept is bad; if the same device 
allowed you a sensible, uniform entry of normal information (times, 
dates, channels, and so on) I think it would be a boon. My objection 
is that it is a use of technology in exactly the wrong direction; using a 
more obscure "code" to record makes you a slave to the VCR Plus. 
"Human readable" program listings in the newspaper are now trashed 
by additional redundant information and in the case of an absent list- 
ing you must call to find out the "secret code". 

If you aren't willing to expend the effort to learn to program your 
VCR, you probably aren't going to thrive in a technological society. 
VCR manufacturers can try to make the task easier, but there is a 
point at which the process cannot be simplified without penalizing 
those who are willing to adapt, 

We run into similar dilemmas as computer users. Many users 
today do not want to learn any programming to use their systems, but 
they also want the systems to act exactly as they wish. Cost can also 
be a factor; generally if you pay enough money, you can have most of 
your first two wishes, even if you have to hire someone else to com- 
pile your dream system from scratch. 

Apple's philosophy of personal computers is based on a model of 
interdependency. As an example, Apple manufacturers computers, 
system software, and printers that are relatively tightly bound to each 
other so you can have programs like GraphicWriter III {for the ligs), 
and XPress (for the Macintosh) that allow you to design and print doc- 
uments of varying complexity without having to enter tedious details 
about your printer. 

The drawback is that the printer you want to use has to be support- 
ed either by the specific software package (on the Apple II) or the 
operating system (for the Mac or native lIgs programs, where printer 
drivers are part of the system software); if you can't select the printer 
you want from the "pre-approved" list or if the implementation of the 
driver is not "complete" in your eyes, you're out of luck (unless you 
have the time and skill to implement and install your own driver). 

Tom Weishaar dealt with the specific issue of printers in "Special 
issue: Solving printer problems" in the November 1985 OpeU' Apple 
[Al'Centrs^s old name). The major quote from that article remains 
true; 



The bad news is that the only person who is in a portion 
to solve YOUR printer problems is YOU. You are the one 
who selected the particular combination of hardware and 
software you have — there may be fewer than a hundred 
other systems exactly like yours in the world. 

You are ultimately limited by what a system's hardware and soft- 
ware will let you do. Actually, in the real worid where finances and 
time are involved, you may be limited by what a system's hardware 
and software will let you do cheaply and easily. 

There are ways that you can get more control over your sys- 
tem. Most involve an education curve and only you can decide 
whether any improvement is worth the investment of your time to 
implement it. If you don't have the time or inclination, you may have 
to spend money, and if you don't want to invest the time, effort, or 
money then it's time to contemplate whether the computer was actu- 
ally a good investment for you. Most of these decisions need to be 
made before you invest in a computer and re-evaluated when you add 
software or hardware. These days we're usually involved with people 
in the re-evaluation stages. 

Hardware is easy to change, and sometimes that is the cheapest 
solution. Saving $100 on a printer is no bargain if it takes you 20 
hours to get it working and your time is worth over $5 an hour. Simi- 
larly, it isn't exactly reasonable to buy a lower-cost printer and 
assume that someone else will get it working for you. The same goes 
for most other hardware items; follow the proverb that says "pay the 
money and cry once". Something isn't cheap if it doesn't work or 
requires constant tweaking. 

Software is generally harder to change because it is even 
more labor-intensive to alter. As the demands upon the hardware 
increase the software also gets larger and more complex; most peo- 
ple don't sit down and write their own software from scratch these 
days (as they might have ten years ago) for that reason. Modifying a 
program that has been written by someone else can be even more dif- 
ficult; you first have to figure out how the original program works, 
then see if it is feasible to add code to modify the program. In many 
cases, modification isn't realistic. (Many people who wouldn't dream 
of asking someone to modify printer hardware seem to think modify- 
ing programs is somehow "easier"; in most cases, it isn't.) 

Fortunately, some software is designed to allow user customization 
and even control. But we're back to the VCR problem: if you want the 
software to do what you want, you have to be able to tell it what you 
want. That means learning to program, whether or not you like the 
idea. 

There seem to be many users interested in learning how to pro- 
gram their systems, if the "guru" factor can be removed. We are mov- 
ing into an era where the common programming languages are appli- 
cation-dependent macros, scripts, or even complete new languages 
like HyperCard's HyperTalk. With application-specific languages prolif- 
erating, requests for programming assistance are becoming as varied 
as printer requests, and it is as difficult for one person to know all the 
answers as it is with printers. 

To be "universal", the focus on learning to program has to be on 
the elements of design that are common to all languages. Users have 
to adapt a problem-solving mentality and the associated skills. The 
Job of translating the ideas into a specific language is then reduced to 
a more mechanical procedure. 

The computer language itself is not the key to the solution. If 
you hold distaste for programming, first forget the images of High 
Priests spouting computerese gibberish in COBOL or FORTRAN that 
are usually associated with the word. A program is only a series of dis- 
crete steps applied to produce a specific effect. Those steps can be 
described in your spoken language — English, French, German, Ital- 
ian, or whatever. As a matter of fact, it's preferential to write the pro- 
gram description in your spoken language before you start doing any- 
thing else. 

If you have trepidation about programming, this realization should 
remove it. You do this type of problem-solving every day. To enter 
your house, you may need to insert a key, turn it, turn it back, 
remove it, grasp the doorknob, turn it, push the door open, and 
release it. Your specific program may vary, and you normally don't 
stop to analyze the steps, but the point is you can do this. You do it 
every day. 
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Of course, there is a certain drudgery in breaking everything down 
into 'baby steps*, and unfortunately computers require you to be very 
expiidt since they aren't veiy intelligent A computer can execute 
instnictions very quictdy, but it only understands what it is told, and it 
has a limited vocabulary. When the computer reaches an instruction it 
doesn't understand, it will either misinterpret it (venturing into some 
alternative path until it can no longer proceed) or will simply be 
unable to do anything and stop. This is one way "computer errors" 
(actually enrors from the human writing the instructions) occur. 

If you want control over your system, you will have to decide to 
deal with the drudgery. Think of the VCR Flus; if you can't (or won't) 
make the effort to solve the puzzle, you will have to live with what 
others hand you. 

Programming in your native tounge. The Hrst step in designing a 
program, whether it is in a "traditional" computer language or an 
application-specific language, is to sit down and analyze how the task 
you want to automate is performed. That is, how would you explain 
the steps involved in the operation to a person who had never per- 
formed the task before? 

imagine the instructions to average three numbers as provided by 
someone else. The person doing the avenging has to get each of the 
three numbers to average, add them together, then report the aver- 
age. But assuming they don't know what 'average' means, this may 
have to be refined further stepwise: 

1) Get and record the first wMxi. 

2) Get and record tbe second rn^m. 

3) Get and record tbe third niber. 

4) Mi tbe first and secood la^xt and record the result as tbe first sm. 

5) Add the third mte to tbe first sun and record it as the seoood sta. 

6) Divide tbe secood m ligf tfaiee and teooitd as tbe fiail annir. 

7) SBpott tbe final mm. 

The tedium starts to show as we move further toward the realm 
where we assume nothing about the entity performing the averaging. 
Well, actually we still have to assume some things, such as their abili- 
^ to add and divide. 

Once you have the problem explained in natural language, 
you come to Uie book woilu learning enough about a programming 
language to translate the actions. You must understand how the 
actions are phrased in the computer language. And you must also 
know what won't translate directly and therefore must be further sim- 
plified or redefined. 

In terms of computers, the programming environment you write for 
will have varying degrees of knowledge. At the lowest level a comput- 
er only understands a very limited number of instructions that per- 
form very limited actions. For example, the 6502 microprocessor in 
the Apple II works primarily with 8-bit values (numerical values 
between and 255) and is limited to moving these values around In 
the computer's memory, addition, subtraction, comparisons, and a 
few c^tr operations. Everything else, even multipiication and divi- 
sfdn, must be derived by programs constructed frbm these basic 
operations. 

The level also affects how many details we must luiow about how 
the computer itself worlds. The lower the level of the computer lan- 
guage, the more the programmer must know about the computer 
itself. That's why machine langu^e (the 'native' language of the com- 
puter) is the most tedious of sdl. Most of us strive to use something 
with more powerful commands. 

As we move up the programming langu£^e scale and isolate our- 
selves further from the 'guts' of the computer, our environment 
becomes more sophisticated in terms of its command vocabulary but 
may become more restrictive in what can be accomplished. For exam- 
ple, writing a disk operating system (which has to communicate 
directly with the disk hardware) in Applesoft is not feasible. Having 
the problem carefully defined in a language we understand helps us 
determine which computer language we should use to solve it. 

Users seem to have different levels of intimidation. Asking a user 
to write a BASIC program to solve a problem may result in frustration. 
Yet we've run into very few users who feel intimidated by writing a for- 
mula for a spreadsheet. It is key to recognize that the act of 
programming is generally the same and the differences lie mainly in 
the syntax and relative power of the target "language*. 

What we'd like to do is look at the progression from a 'classic' lan- 
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guaqe like ^plesoft to application-specific languages. Tills is not 
meant to teach any of these languages in a few paragraphs; normally 
you would learn the langu£^e firom books or possibly in a classroom. 
What we want to get across is that programming should not be intimi- 
dating and that languages are progressing toward a form that we 
believe will encourage their use. 

The translation to a 'real' programming language. Assuming 
weYe content to take the shortest route to a working solution for our 
averaging problem, the conversion to Applesoft is straightforward 
from our stepwise description. The overall problem is still the same: 
allow the user to enter three numbers, calculate the average, and dis- 
play it. One way of solving this in Applesoft is a near-literal translation: 
10 sn 

15BGK 

20 BRU ficst: Ml 
mnra'Seooai: 
40 INPUT ^lEidrd: ^;HI 
50 SI = Nl + IC 
60 S2 = SI + IG 
70 M = S2/3 

aO FRBR 'Ibe aveiage is \-Al;".'' 

There are some differences fi'om our English program. In Applesoft 
we have to have a distinct identifying number for each instruction 
line; lines in the program are executed in the order of these numbers 
unless we use an Applesoft insfaruction (not among those used above) 
that causes a line to be executed "out of order*. Also, although the 
w<»ds TEXT, HOME, inPUT, and PRIIiT have meaning to us, they have 
nanowen specific meanings to Applesoft. As in English, these lan- 
gu^c protocols are referred to as syntax, and the syntax of a program 
has to be conrect for a computer to run it. Absolutely conrect, because 
the computer is very bad at reading between the lines. 

If you are unfamiliar with Applesoft, why and how the above pro- 
gram works may be a mystery. But even if you're intimidated by pro- 
gramming, it should also be apparent that we haven't moved very far 
away from our original description. What we have is a problem in 
translation, not some mysterious black magic. If you have the logical 
problems ironed out in your native-language outline and make the 
translation accurately, the program should run and produce the cor- 
rect results. 

The first line (TEXT) puts the screen in text mode, the second 
(HOME) clears the screen and puts the cursor in the upper left-hand 
corner; you might think of the combination as getting a blank sheet of 
paper to work on. iriPUT allows us to print a prompt (the text within 
quote marks) and receive an answer typed from the keyboard into a 
variable (the item after the semicolon in each line). The equations in 
lines 50-70 perform the math, and line 80 displays the answer on the 
screen. 

To execute the progranri, we use the cx)mmand word RUM. Issued 
while our program is in mem(Hy, RUN causes ^plesoft to clear the 
values of any variables and start executing our program at the first 
line When prompted, we enter our three numbers, and Applesoft 
prints the answer. 

Because Applesoft is sufflciendy sophisticated to handle the math 
in a single equation (humans usually add only two numbers at a 
time), we are able to combine the calculations in a single step: 

10 TEXT : BCIfi 
20 mm "First: ';M1 
30 niPDT ^Secood: \'N2 
40 mn rChiid: ";N3 

50 PRINT 'Ifae average is (lll4824H3)/3;\'' 

If we wanted to try to duplicate the appearance and function of an 
AppleWorks spreadsheet the program would obviously be much more 
complex, but it is possible to write Applesoft programs that aspire to 
such imitative sophistication. (For an example of an Applesoft pro- 
gram that duplicates the "look and feer of the AppleWorks datat^ 
display, see "Reading AppleWorks data bases", March 1987) 

Redefining the solution in an AppleWorks environment. Unlike 
Applesoft, AppleWorks's spreadsheet module provides the screen for- 
matting and entry routines for us; PRINT and INPUT statements disap- 
pear. The penalty is that we have to start AppleWorks (a rather large 
prt^ram compared to Applesoft) in order to use the program. 
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Assuming that we don't want the three numbers to be part of a per- 
manent formula, if we were to suggest a method of solution it would 
probably be to "enter each of the three numbers into a cell then cre- 
ate a fourth cell who's value is the average of those three numbers". 

Laid out in a spreadsheet (with column and row labels), the solu- 
tion might look like this: 

A B 

1 First 1.2 

2 Second 2.4 

3 Ihird 4.8 

5 2.8 

The formula for the "Averages" cell (B5) could be done in a few dif- 
ferent ways, but we'll choose to use the @AVQ function: 

@AVG(B1...B3} 

If there were a programming language for the AppleWorks spread- 
sheet, the program to create this spreadsheet from the main menu 
might look like this: 

type n" 
type return 
type ^^5" 
type return 
type 'T 
type return 
type ^^Sanple.SS" 
type return 
type ^irst" 
type down arrow 
type "Second" 
type doMi arrow 
type "Third" 
type doNn arrow 
type rig^ arrow 
type quote 
type 

type down arrow 
type"@AVG(Bl...B3r 
type return 

All of these instructions involve entering data at the keyboard. We 
use "type" followed by the name of the character ("return", "quote", 
"down an'ow") or text in quote marks to indicate what needs to be 
typed. It's tedious; doing it is a lot easier than saying it. But it fulfills 
the basic requirements of a program: it is a finite set of stepwise 
instructions you can follow to create the spreadsheet. You could even 
read it to someone over the phone. 

You might not think of this as a "program" since it requires a 
human to execute each step; the sequence is not processed automat- 
ically by the computer. However, now having defined the spreadsheet 
solution in English, we're only a step away from converting it into an 
"AppleWorks program". 

Many 'programs' these days actually refer to a capability for 
the use off macros or scripts. We'd normally think of macros as 
recorded sequences of keyboard actions. To our notion, scripts are 
series of commands that are entered into a program from a text file, 
but the distinction between macros and scripts sometimes gets hazy. 
For example, TimeOut UltraMacros allows you to record a series of 
operations within AppleWorks as you type {a macro), or to define sim- 
ilar actions by entering command words into a word processing docu- 
ment and then "compiling" those commands into a form UltraMacros 
can work from. 

Using the UltraMacros program, we can take our "spreadsheet gen- 
eration" instructions above and look in the UltraMacros manual for its 
syntax to duplicate them. As with Applesoft, part of the operation is 
adding any other structural components the program requires. 

The UltraMacros compiler requires the word "start" at the beginning 
of the macro definitions. Following that, there is the macro key to be 
defined: we used "<ba-S>" ("both apple ess") to indicate the macro 
will be triggered by pressing the open-apple and closed-apple keys 
and the "S" key simultaneously. Following that is a colon, then the 



AppleWorks module that the macro will work within (we used '<all>' 
meaning our macro can be called up from any module). The nest is all 
instructions the macro is to cany out, ended with a "!" to mark the 
end of the macro for the compiler. 

UltraMacros has other syntax requirements. Certain command 
words used by UltraMacros must appear within angle brackets ('<' 
and ">"). There are special command abbreviations like "oa-Q' (open- 
apple-Q) to indicate the typing of an AppleWorks command key 
(open-apple-Q brings up the "quick switch" menu that allows chang- 
ing to a different file on the desktop). Some keys that aren't repre- 
sented by printable characters have special names (like "rtn" for the 
Return key, or "right" for the forward arrow). Where there are several 
command words (also called "tokens") in succession, they can be 
placed within a single pair of angle brackets with a colon placed 
between commands; that is, "<all><oa-Q><esc>" and *<all:oa-Q:esc>" 
would be treated the same. 

"White space" (non-printing characters used to format the file, 
including spaces, tab characters, and return characters) within brack- 
ets is ignored. Characters within curiy brackets {"{" and ")") within 
and ">" are also ignored; this allows us to enter "comments" to 
explain the macro without the comments interfering with interpreta- 
tion of the macro. Return characters at the end of lines are also 
ignored (you need to use the "<rtn>'' token to generate a return char- 
acter as if it were typed from the macro). 

Characters typed outside of the brackets are sent to AppleWorks as 
if they were typed at the keyboard. That is, "1 <rtn>" would be treated 
as if you typed the 1 key, the space bar, and the Return key in suc- 
cession, 

start 

<ba-S>:<all {use frcn any mM&)> 

<6a-Q {put up quidc-8Nitcfa}> 

<mc {escape to nain ibqu}> 

Krtn {W}> 

5<rtn {new file for SS}> 

l<rtn (from scratch)> 

SaiBple.SS<rtn (fUe nane)> 

First<dONn {text for cells}> 

SecQQd<down> 

Ihird<down> 

<right {next colw}> 

t {label}> 

<d0Nn> 

e&VG(Bl...B3)<rtn> 

! {end of oacro} 

Okay, it's a little intense tiying to boil down a programming lesson 
into a few paragraphs. But the point is that if you can understand the 
English version above, with a little work and our few hints above you 
should be able to understand the UltraMacros "program". (When we 
surveyed users last year, UltraMacros was the leading "programming 
language" in use by our customers.) 

Other macro and scripting environments (from Roger Wagner Pub- 
lishing's MacroMate to the script languages of communications pro- 
grams such as Talk is Cheap, Proterm, and Poirtt to Point) have differ- 
ent syntax, and the responsibility of learning the syntax falls upon the 
user wanting to customize the program. If you start with a clear idea 
of the problem in your own words, you should be able to work out a 
translation into the target language by expending some effort. And as 
you learn the syntax, the chore will become easier and more auto- 
matic, to the point that experienced programmers often sit down and 
start writing in the target language. 

Hypermedia: the next frontiei? Even discounting the addition of 
sound and video to hypermedia programs, just the incorporation of 
the non-linear linkages and graphical elements usually employed in a 
hypermedia "program" makes it more complicated to describe in 
purely textual terms. Since we have to think in textual terms first to 
write our native-language description of what we'd like to incorporate 
into a program, descriptions of hypermedia programs can become 
very complicated even if the individual elements are simple to 
describe. 

For a hypermedia program without explicit scripting capabilities 
(Tutor-Tech and fiyperScreen on the Apple II, and Hexus on the Ilgs) 
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the data file itself can still be seen as the program. Program design 
consists of determining how the various elements of cards, fields, 
and buttons (files and links for fiexus) will combine to control the 
ways the user can navigate and experience the data. 

Both HyperStudio and HyperCard Ilgs have scripting capabilities. 
But HyperCard's use of scripts is integral to the operation of the pro- 
gram while HyperStudio's mostly allows control over external com- 
mands. The things that this scripting allows you to do make the flavor 
of the programs different, though there is some overlap. 

HyperStudio's out-of-box functionality is so completely encom- 
passed by its visual interface and environment that it is not necessaiy 
to use scripting to operate it. With the addition of the Master XCMD 
from the HyperStudio XCMD Library DisK Volume J, operations 
involving XCMDs can be scripted. But since much of HyperStudio's 
internal operation (such as painting, adding buttons, and so on) does 
not require scripting, it's harder to describe HyperStudio's stacks only 
In terms of 'scripts", at least in our 'programming" sense. 

HyperCard's scripting language, on the other hand, can control all 
aspects of the program and gives us a way to completely describe the 
implementation of a stack textualiy. Tor example, going back to our 
'averaging' problem, if we create three fields for input and one for 
the answer, the code for displaying the average can be placed in the 
script of a "result" field: 

on nous^er 
put false into nullField 
repeat with 1 = 4 to 6 

if card field i is e^pty then put tzoe into nullField 
end lepeat 

if not nullField then put avecage(caEd field 4, caxd field 5, cazd field 6)-; 
into card field 7 
else put W into card field 7 
endious^ater 

If we enter valid data into fields 4-6 and move the mouse into the 
result field 7 (triggering the 'mouscEnter' handler above), the aver- 
age of fields 4^ will be placed in field 7. (If any of fields 4-6 contains 
something other than a number, an enor dialog will be displayed; we 
haven't implemented en^or trapping.) 

If we'd like to specify aU stages in creating the fields on a blank 
card in a new stack, our 'averaging' program can be expressed com- 
pletely in HyperTalk. In general terms, we save the current tool and 
pattern, then paint the background. We draw and position seven card 
fields: three to hold labels, three more to accept our data, and one to 
hold the result. Then we create a variable holding the same script we 
used above, add it to the seventh field, and finally restore our original 
tool and paint settings. Even without a line-by-line analysis of the 
program it should make sense: 

on averageCard 
put the tool into oorTool 
put the patten into ou^atton 
choose bucket tool 
set the pattern to 4 
cUdc at 160,100 
choose field tool 
dGlfBaa ^ Field" 

set the rect of card fUld X to 50,50,150,62 
put ""First" into card field 1 
dcMenu "Sev Field" 

set the rect of card field 2 to 50,70,150,82 
put ""Seoood* into card field 2 
dcNeim 'Nev Field" 

set the rect of card field 3 to 50,90,150,102 
put "Third* into card field 3 
repeat with i = 1 to 3 

set the style of card field i to opaque 

set the lodcText of card field i to true 

set the sbovLines of card field i to false 
eDd repeat 
ddfem liev Field" 

set the rect of card field 4 to 160,50,310,62 
doMeou "Nev Field" 



set the rect of card field 5 to 160,70,310,82 
doHem "Neir Field" 

set the rect of card field 6 to 160,90,310,102 
dotted Field' 

set the rect of card field 7 to 160,110,310,122 
set the lodcTeit of card field 7 to true 
put W into card field 7 
repeat ifith i = 4 to 7 

set the style of card field i to opaque 

set the showLines of card field i to false 
end repeat 

put ""on nous^er" i return &-> 
''put false into nullField" & return &-i 
''repeat with i = 4 to 6" & return i-. 

""if card field i is enpty then put true into nullField'' & return &-i 
''end repeat" i return &-i 

*ii not nuUField then put average(card field 4," SSn 
''card field 5, card field 6) into card field V & return &-> 
Mse put" &t quote & 1ft" £ quote » "into card field 7% 
( return &-i 

"end aouseBoter" & return into newScr^ 
set the script of card field i to nemScript 
dioose ourTool 
set pattern to ourPattem 
end avera^pCard 

We added this handler to the stack script, brought up the message 
box and typed *averageCard'. All that was left to do was to sit back 
as HyperCard paints the card, creates and positions the fields, sets 
their properties, and places our script into card field 7. notice that 
the syntax here is noticeably like a natural language; eventually, 
maybe you'll be able to describe what you want to the computer in 
everyday language and have it created. (Or maybe our "everyday lan- 
guage" will adopt computer jargon by that time.) 

The core of hypermedia design will probably redefine how we 
thinl( of programmers in the ftiture. The 1970's microcomputer 
programmer dealt largely in paper and cassette tape, machine lan- 
guage, and text-only terminals. In the 1980's, use of graphics became 
wider and even expected, culminating in the more extensive incorpo- 
ration of graphics into the user Interface on most surviving microcom- 
puters. 

In the 1990's, a programmer has to be not only a linguist and 
rational thinker, but also an artist, poet, motion picture director, 
screenwriter, and so on. We learned this as our first issue of Saipt- 
Central was assembled; we've added individuals with art experience 
(Steve 'Bo" Monroe) and knowledge of sound (Bruce "Han^ime" 
Caplin) to our stressed-out editorial staff. We still think the "English 
first, program second" method of development is the right way to go, 
but the form of the En^ish description is going to start reading less 
like a checklist and more like a motion picture screenplay, complete 
with visual and musical direction. And computer programs are going 
to start looking more like interactive videotapes than blank paper 
forms reproduced on a computer screen. At some point in the future, 
a person programming a computer may resemble a director for a 
stage or motion picture production. 

But at eveiy stage, what should be apparent is that program 
design is not really a function of the computer. It is the definition 
of the problem in specific instructions that someone else can follow. 
The implementation of the instructions is where the knowledge of the 
computer is needed; you may have to revise some of your original 
instructions to fit them into actions the computer can perform (and 
the computer language can express), but there's no reason the 
descriptions of the process can't remain in English. 

There is no shame in having no desire to learn how computers 
work. But if you want to understand books you have to learn to read, 
and if you want to drive a car you have to get a license. If you want 
control over your computer system you'll have to learn how to apply 
logic in terms it can understand or hire a consultant to apply it for 
you. But please, don't ask for VCR Hus solutions; the idea is to 
release the power of computing to everyone, not to lock it in a box 
that requires a call to a 1-900-number every time you want to do 
something interesting.— DJD 
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RGB switch 

I have an Apple He with Applied Engineer- 
ing's RamWorks III and the CoiorLink option. I 
also have a Magnavox RGB monitor. I have had 
a problem similar to Mr. Mastel's ("Apple RGB 
connections", p. 7.21, April 1991) with pro- 
grams showing up in grey scale. For me it has 
been ones from Broderbund such as The Hew 
Print Shop, Dazzle Draw, and The Flayroom. 
These programs also created so much screen 
flicker under RGB that they could not be used. 
Fortunately lean also connect the composite 
ports and the RGB ones at the same time and 
switch back and forth between the two as need- 
ed via the front panel on the Magnavox monitor. 
Even my three-year-old has mastered the tech- 
nique. 

Gary Sonnenburg 
Omaha, Deb. 

SiderlRamFast support 

C.V. Technologies announced the release of 
ROM 2 for the RamFast SCSI card which sup- 
ports tape drives. Being an owner of a Sider 
C96 and RamFast 1 was anxious to purchase 
ROM 2. About a year ago, I elected to give up 
my tape backup capabilities for the RamFasts 
unbelievable speed. At that time C.V. Technolo- 
gies was planning tape drive support with ROM 
2. Usually anything that is worth a darn takes a 
fair amount of time to perfect. In this case it 
was no exception. When I received ROM 2 it 
consistently locked up the tape drive... ack! 

C.V. Technologies and I probably sent more 
missiles back and forth than the U.S. and Iraq. 
Finally, I listened to Andrew Vogan and sent him 
my C96. Andrew spent the better part of two 
days tracking down the problem. It turns out 
that the microcontroller on the tape drive was 
not fast enough to handle the RamFasts warp 
speed. He called the manufacturer and found 
that they had a new model that would work. 
Andrew returned the drive and told me to con- 
tact Lany Beyer of B fif D Computer Repair in 
Chicago. 

Larry installed a new microcontroller and 
thoroughly tested my C96. The tape drive is 
now incredibly fast thanks to C. V. Technologies 
and B 8f D Computer repair. 

If you want great products and service for the 
Apple II make sure that you use these compa- 
nies! 

Q. Scott May 
Buffalo Grove, III. 

B8tD Computer Repair's address is 61 15 5. 
Massaholt Chicago. Ill 60638, 31 2-755-90 10, 
Larry has been handling Srder repairs for sev- 
eral years.— DJD 



Beagle Compiler and "&" 

There's a way for assembly language pro- 
grams to tell whether they've been called from 
pure Applesoft or from the Beagle Compiler, 
because I've done it. Just use two charac- 
ters to start each of your ampersand calls, as is 
suggested on page 20 of the Beagie Compiler 
manual. Regular Applesoft will gobble only the 
first "8f" character as it joins your assembly lan- 
guage routine. Compiled "Beaglesoft" will gob- 
ble both of them. The first thing you do in your 
routine is JSR CHRQOT (JSR $00B7) to get the 
current character pointed at by TXTPTR ($B7- 
B8). If it's an then you're running under 
Applesoft. If it's not, you're running under the 
compiler. 

Actually, you need to check CURLlfi+l ($76) 
first to see if you are working in the immediate 
mode. If it is $FF, then the entry in your "&" 
code is occurring during immediate mode and 
not during program execution; you would want 
to use routines compatible with Applesoft under 
that circumstance. 

You should make extensive use of Apple- 
soft's built-in syntax checking to gather your 
variables and send back your results, and ail 
will be well. 

Craig Peterson 
Santa Monica, Calif. 

This technique doesn't seem to work with 
the more recent editions of the Beagle Com- 
piler, but Craig's basic advice is sound: check 
to see if the compiler or Applesoft is interpret- 
ing the program code, then jump to the appro- 
priate "St" handler. 

We found that the CMRGOT routine is differ- 
ent with the compiled code running; you can 
verify this by checking location $B7. The con- 
tents under Applesoft are $AD (IDA $xxxx), 
under the compiler the location contains "$AC'' 
(LDY $xxxx). Checking that location will if the 
compiler is running with the cutreat version; 
this method is neither sanctioned nor guaran- 
teed by Beagle, but the manual gives no ID 
bytes" for determining if the compiler is exe- 
cuting the program. (Beagle is looking into a 
"guaranteed" way for us.) 

The next trick is catching the "8t". Applesoft 
actually converts Its keywords Into one-byte 
representations ("tokens") to make the pro- 
grams more compact. Token values are always 
In the range $80 to $FF (text embedded in the 
Applesoft program is represented in the ASCII 
range $00 to $7F), and the token for the "8t" 
command is $AF. So you need to check for 
tiiat value rather than the ASCII value for "8t" 
($26). 

When we put the above changes in with 
Craig's design, our dummy subroutine to test 
parsing a double ampersand looks like this: 



CDRUNE 


(XQtJ 


$0075 


cunent line tsmbet 


CHBGOr 


GEQJ 


$00B7 


get current character 


TXTPTR 


(XQtJ 


$00B8 




COOT 


(SQU 
<XG 


$ET]eD 
$0300 




Entry 


SIKRT 
Ida 


CORLIKB+l 






csp 


m 


iiiBediate? 




beq 








jsr 


CBR90T 








t$AF 


AS token for \" 




beq 
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Ccqpiler 
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Imnedl Ida 


msgl^x 




beq 
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jsr 


COOT 




inx 






Cue 


Inaedl 
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fl'8D',C'IiiBBdiatefflode... \H'8D00' 


Interp Idx 
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jsr 


Biii|:Ptr 




Ida 


(TXIPTRrx) 
«$80 




ora 
jsr 


COT 




Ida 


r ^ 




jsr 


OODT 




Interpl Ida 


]nsg2,x 




beq 


Exit 
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OCOT 




inx 






bne 


Interpl 




ins92 DC 


H'8D',C'J^ 


ilesoft interpreter', H'SDOO' 


Coopiler Ida 


ll$87 


be^ twice 


jsr 
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COOT 
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#0 




Ida 


(TXlFTRfX) 




ora 


jt$80 




jsr 


(xm 




Ida 


¥ ' 




jsr 


COOT 
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beq 


Exit 




jsr 


COOT 
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bne 


Coopilrl 




asg3 rc 


r8D',C'Beagle CQn{)iler',fl'8D0O' 


Exit jsr 


BuniPtr 


move past '^X" 


clc 




sate A/S happy 


rts 




return 


BunpiPtr inc 


Tlt!I?ER 




bne 


PtrCK 




inc 


TXIPTR+1 




PtrOK RTS 






QD 







Line 30 in the following BASIC program 
installs and calls the routine (the K in line 30 is 
not used as a command, just echoed by the 
subroutine): 

10 PRINT CHR$ (4};'WADA»FER": REM at $0300 
20 POKE 1013,76: POKE 1014,0: PC8S 1015,3 
30 & & X 

There are still problems the programmer will 
need to resolve. First safe memory has to be 
found for the routine (safe with Applesoft or 
the Bea0e Compi/er environment). Second, 
support routines are different in the two envi- 
ronments; Applesoft's routines are in ROM, of 
course, and the Bea0e Compilets routines 
are part of the COMFILER.SYSTEN file loaded 
to run compiled programs. If your ampersand 
routines need to call these support routines, 
the addresses for Applesoft and the Bea^e 
Compiier will be different 

The support routine addresses and func- 
tions for the Beagle Compiler are located in 
the compiler's manual. Apple's Applesoft docu- 
mentation doesn't list Applesoft internal rou- 
tines, but one source is Assembly Language 
for the Applesoft Programme by C. W. Fin- 
ley, Jr., and Roy E. Myers. (Addison Wesley, 
ISBIi #0-201-05209-1).— DJD 
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Boo, hiss 

My Ilgs system includes a ROM 01 CPU, a 
TransWarp GS with 32K cache, an Apple High- 
Speed SCSI interface, and an Applied Engineer- 
ing QS-Ram Plus with 3 megabytes installed. 

I recently received version 0.95 of Sound- 
Smith from Huibert Aalbers, Since my onboard 
speaker doesn't do justice to the music this 
software produces, I plugged a portable stereo 
speaker into the computer's headphone jack. 
This works fine when the music is playing, but 
there is a very audible hiss when the music is 
off. 1 realize the Ilgs's internal speaker makes 
the same hiss, but it is pretty much drowned 
out by my System Savefs fan. 

Is there a practical way to reduce or elimi- 
nate the noise the computer produces? In the 
September 1989 newsletter ('Apple upgrades 
Ilgs hardware") you wrote that the ROM 03 Ilgs's 
have "cleaner sound*. Does this mean newer 
Ilgs's have less hiss? 

Is there a better way to connect a single 
speaker to the Ilgs than using the headphone 
jack? I don't want to invest in a sound card and 
stereo speakers, but a single amplified speaker 
is worthy of consideration. 

Stephen Qant 
Manteca, Calif. 

Fart of the hiss pmblem on ROM 01 
machines has to do with the drcuitiy layout on 
the nwtiierboarti. Any dfcuit carrying electron- 
ic signals tends to ad as a broadcast antenna 
for those sigmds; if another circuit lies within 
the 'broadcast re^on' some of the signal can 
'cross over' to the second circuit (this type of 
interference is referred to as 'crosstalk'). The 
audio circuits on the RON 01 machines are 
dose enough to certain other circuits to pick 
up interference from them. This can't t)e 
changed without altering the motherboard; it 
was alleviated on the ROM 03 motherboard by 
changing the circuit layout to better isolate the 
audio circuits from possible interference 
sources. 

I have a ROM 01 at home and haven't found 
the hiss to be that objectionable. The easiest 
way to reduce it is to lower the treble response 
on your speaker system; I've found this 
doesn't seem to affect the sound quality too 
extensh^ely. 

A stereo card may help; I do notice less hiss 
on my SmucM^Hii'soutj)ut—DJD 

More GS/OS versions 

m the latest AFDAhog (April 1991), there is 
no mention of Apple Ilgs System 5.0.3. Is this 
an unreleased version which is basically the 
same as System 5,0.4? This would also mean 
that 5.0.3 only works for a ligs with one 
megabyte of memory and above, I presume. 

A. Hadiwidjaja 
Ashfield, n.S.W. 

Sy^em 5.0.3 was only 'semi-released"; it 
never made it to Apple dealers, for example. A 
few obscure problems in 5.0.3 forced a revi- 
sion to version 5.0 A, which was released a few 
months later. 

A convenient way to break down the Ilgs 
System Software versions is by system require- 
ments. System 3.2 was the last version that 
would run on a basic 256K machine, but its 
use can't be encouraged since the Ilgs toolsets 
have been revised drastically since it was intro- 
duced. 

System 5.0.2 will operate on most 5l2t{ 



machines; the use of AppleShare or the addi- 
tion of the newer SCSI drivers provided with 
the tligh-Speed SCSI Card support disk may 
push the memory requirements slightly over 
that 

For systems with one megabyte of memory 
or more. System 5.0.4 is the "current' recom- 
mended system software. Ilgs users who have 
less than one megabyte of memory should 
strongly consider upgrading; memory prices 
are very reasonable now, and use of the cur- 
rent system software version is necessary to 
have access to software that uses features 
found only in the newer versions. We generally 
recommend Ilgs owners aim for at least two 
megabytes of memory to give themselves 
some "breathing room'.—DJD 

900 number gotcha 

After reading the letter from Mike Sample in 
the June 1991 issue, I would like to point out a 
problem with 1-900 lines that many people do 
not know exists. Due to a change in Texas law 
to prevent abuse of 900 and 976 numbers, tele- 
phone companies that cannot block service to 
these numbers on a customer by customer 
basis must completely block service to these 
numbers. Being served by such a telephone 
company, I am therefore legally blocked from 
calling Applied Engineering's or any other 1-900 
number. This affects many users who live in 
rural areas where there is already no convenient 
dealer or user group. 

As a professional systems analyst/program- 
mer who has used Apple computers since 
1980, I fortunately have had little need to use 
telephone support lines. However, I would 
encourage companies to rethink their use of 1- 
900 numbers so that others served by tele- 
phone companies affected by this law will not 
lose one of the few resources available to them. 

Charies W. flail 
Comfort, Texas 

The use of 900 numbers is generating con- 
troversy for all types of computer products, 
William F. Zachmann's editorial in the July 
1991 (Vol. 10, no. 13) issue ofFCMaganne 
is 'For a Good Time, Call iWOSUFFORV. He 
looks at the issue critically, but misses your 
predicament. 

One of the other bizarre developments is a 
mail-order house that uses a 900 number for 
produd orders. The company clainis that this 
allows them to sell products at a lower price by 
offsetting sales support costs. Those who ask 
Uie most questions pay the most in telephone 
charges.—DJD 

Disl( fading 

I'm thinking about taking the plunge and buy- 
ing a hard drive. I went back through a couple 
of years of Al-Central and couldn't find the 
answer to this question. 

All of the information on the disk is magneti- 
cally imprinted, including the low-level format- 
ting. Some of this information will not be called 
up and renewed for long periods of time, 
maybe years. Will this information gradually 
fade and cause disk errors? If this is a problem, 
could a layman save everything he had on the 
disk including the high-level formatting, renew 
all the original formatting and put Humpty 
Dumpty back together again? Maybe there is no 
problem wfth magnetic fading? 

I could stand to renew the formatting every 
other year better than introducing, say, a 0.005 



per cent en-or factor. With the millions of opera- 
tions that go on in the computer every boot and 
run, I have visions of my software slowly devel- 
oping bugs and glitches after a few years, I have 
had a few programs on floppies go bad slowly. 
You can recover from one floppy; I shudder to 
think about the same thing happening to a hard 
drive. 

Rollin Ratchen 
Salem, Oregon 

We'd like to reduce your paranoia some. 
Just some, not entirely; you can't see what's 
happening to your data, so it's better to be 
very safe rather than very sorry. 

Technicians have told us that computer data 
on disk media may be good for ten years or 
more, so disks should be re-written (all data 
backed up, the disk re-formatted, and the 
backup restored) at least that often. 

We were also told magnetic tape should be 
rewritten at least every Five years. Since mag- 
netic tape is stored as 'layers' wound on a 
spool tape has the additional problem of 
'print-though", where the magnetic image on 
one layer can try to imprint itself on the adja- 
cent layer, disturbing the original information. 
(This happens on audio and video tapes, too, 
but audio and video tape recorders don't come 
to a crashing halt if their data is slightly distort- 
ed.) 

There are other things in our environment 
that cause magnetic Fields that can corrupt 
data on magnetic media. Hard disks are resis- 
tant to most minor disturbances (otherwise 
you'd have trouble using them close to your 
computer and monitor), but if you have the 
hard disk setting on the floor and start an elec- 
tric motor next to it (say, a vacuum cleaner) 
the magnetic Field exerted by the motor may 
trash your data. 

Also, you have to remember that the hard 
disk itself is a mechanical device with moving 
parts that may wear out long before the data 
deteriorates. A hard disk with a "MTBr (mean 
time between failures, or the average time that 
can be expected to pass before the drive fails) 
of 50,000 hours should have an average life- 
time of between five and six years. If you wait 
ten years to 'reconstitute" it, you're taking 
chances. 

Finally, you have to assume that nothing 
else damages the drive. It's always possible 
that a power surge, rampa^ng program, or 
physical dam^e could take out the drive at 
any time. 

So the rule is simple: back up your data 
regulaify. In case of a failure at any time, you 
won't lose any more work than was completed 
since your last backup.~DJD 

A f lasli of SuperView 

I found a bug in SuperView, the graphic view- 
er you put on your May 1991 disk. With 
AppleTalk enabled, the pictures are interrupted 
with flashes. Disable AppleTalk and eveiything 
works fine again. 

Jack van Soest 
Vlaardingen, Metherlands 

Sup&View is a utility that allows viewing 
Ilgs pictures using up to 3200 colors. The Ilgs 
is normally limited to displaying 16 palettes of 
16 colors (up to 256 colors) when the screen 
is set to use the 320 by 200 resolution mode. 
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In order to get 5200 colors, the llgs palettes 
are altered "on the fly" as the various lines are 
displayed so that a different 16 colors can be 
displayed for each of the 200 scan lines (16 
times 200 is 3200 colors). As you can imagine, 
continuously altering the palettes as the pic- 
ture is displayed takes a lot of work; the pro- 
cessor is kept pretty continuously busy. 

AppleTalk also insists on having access to 
the processor occasionally so that it can check 
on the network status. The 'flash" is caused by 
the handling of an AppleTalk interrupt causing 
the 5200<olor display code to get "out of 
sync" in updating the palettes for the displayed 
image. This could be prevented by disabling 
interrupts, but this could cause the network to 
assume your llgs had been disconnected and 
quit looking for it; not a good thing, especially 
if you're using an AppleShare volume as a pri- 
mary disk drive. 

So it really isn't a 'bug', it was a design 
decision. Chris Mcliinsey (Sup&View's author) 
decided that leaving you connected to the net- 
work was more important than giving you flick- 
er-free pictures. This only affects AppleTalk 
users, and is a limitation of the resources of 
the llgs.-DJD 

MDSASIC an6C 

For those few (like myself) who have the 
need to convert 16-bit C programs to run on 8- 
bit Apples— tiy MDSASIQ The latest version 
supports whiles, repeats, if-then-else, etc., and 
it is fairly easy to use macros to convert 
printfCNnHello') to PWMT "Hello'. I now have a 



fairly large program running under QS/OS and 
nearly the same program running under Apple- 
soft! 

Richard Fhares 
Annapolis, Md. 

Apple's Mac LC "solution" 

I just received the July issue of Al-CeBtrat 
and would like to comment on a couple of 
points. On page 7.44 you say, '...But given the 
limitations of the LC as a host, the erratic com- 
mittment of the parent company to support its 
installed base of users../ Great paragraph! 

In my opinion the Mac LC {and the Classic) 
are the biggest pieces of 'junk' ever placed on 
the market. The LC, I tielieve, will be Apple's 
"Edsel/ f^y church bought one over my severe 
objections and are already sorry for the pur- 
chase and looking for a way out. It's terrible to 
have to tell your minister th£rt 'I told you so.' 

On page 7.45 in Ask Uncle DOS, Robert Halls 
letter title 'Revenge' hit the nail somewhat on 
the head. 1 don't agree completely with some of 
his comments nor your response. I am no 
longer an Apple'er after 10 years of Apple He's, 
lie's and llgg's. I have sold almost all of the 
hardware and a large portion of my extensive 
software and reference libraries. (Thank good- 
ness there is still a fairly good resale market for 
this "stuff".) I am working from an IBM compati- 
ble 386SX clone which sports 4 meg of memo- 
ry, a math coprocessor, a 3.5 drive, a 5.25 
drive, an 80 meg internal hard drive, a 2400 
baud Internal modem and a Hewlett Packard 
DeskJet 500. By the way this system cost me a 
"heck of a lot less' than a comparably equipped 
Macintosh LC would have. 1 run with MS DOS 
5.0 and Windows 3.0. I have been running this 
sj^tem for over a month using WordPerfect 5. 1 
(just waiting for Windows version), Excel 3 for 
Windows (WOW!), dBase IV and PageMakers 
for Windows. Although 1 have suffered some 
"discomfort' with the learning curve, 1 must 
admit that at this point I DO nOT MISS APPLE, 
including AppleWorks which I did not think I 
could ever do without. 

Revenge— I have had mine. I am no longer an 
Apple customer nor will I ever be again. Mot 
only that I am sharing my conversion experi- 
ence with many other former-to-be Apple 11 
owners. I really think it is too late for Apple to 
do anything about the alienation of the signifi- 
cantly large Apple II customer base. 1 think the 
40% per cent drop in their stock value should 
say something. 

I know that Apple is A2'C&itnd's bread and 
butter and this type of letter does not bode well 
for the future, but I dare you to print it. 1 will be 
watching Al-Centrsd until my subscription 
expires next May. I hope to see it in print- 
Raymond W. Crowley 
Manchester, Mo. 

Well, Pm not too fearful of printing it since 
obviously we have a great many Apple II pech 
pie who don't feel the same way. I too have my 
MS-DOS systems, starting with a lai^op to do 
what Apple couldn't seem to achieve; I still 
think the Apple IPs problem is unrealized 
potential rather than lack of potential. 

Apple's stock has been playing ping-pong for 
the last three years, usually boosting after new 
product introductions and then slowly fading 
toward the Christmas buying season when the 
Apple 11^ (which has been pooriy marketed of 
late) was formeriy the traditional seller. The 
intro of the new Macs last fall sent the stock 



zooming and now it has moderated; let's hope 
the new Consumer Products group will have 
something to say about the Apple IPs role this 
season. ~DJD 

Good reasons 

I enjoy reading your newsletter, even though 
/ own a lie and Pmd the number of gennane 
articles diminishing. 

Give me three reasons 1 can present to my 
wife for upgrading to a llgs. If she buys at least 
two of them, I will be both grateful and less 
inclined to fire off letters with snide italic pas- 
sages. 

Robert W. Hughes 
Reynoldsburg, Ohio 

We've covered several of the issues in the 
past, with software being a weak link, so let 
me give you three software reasons to 
upgrade: hypermedia, programming languages, 
and networking. Your decision to actually 
change systems will probably depend on your 
interest in these areas. 

The //gs has the basic hardware to support 
powerful hypermedia f^ograms like Pteim, 
MypeiStttdio, and Hyp&Card Bgs, giving it 
perhaps the most potential in this area. The 
llgs's Individual capacities for sound, color 
graphics, megabytes of memory, and so on 
may not be the most intimidating on the mar- 
ket but it is an affordable way to get the com- 
bination of these capabilities in a ready-to-use 
package. If you're curious about the llgs, these 
programs are worth investigating (we've spo- 
ken about them often ourselves). 

The llgs provides a richer environment for 
classic programming langus^es such as Pascal 
and C, where Apple 11 implementations have 
stuttered. Your choice of languages for the llgs 
is broader, and 8-bit languages are also avail- 
able, of course. In addition, if you like the idea 
of writing using a graphical user interface, 
Apple has already made many of the routines 
available as part of the llgs system software's 
tools. 

Finally, although Apple also brought net- 
working capability to the lie via the Apple II 
WoriiStation Card, the //gs handles networking 
more naturally. The llgs finder supports net- 
work volumes automatically (as should all 
good llgs programs) and has the extra 
resources to allow the use of network printer 
drivers as part of the operating system. And, 
although not strictiy networking, the I ^ also 
has more flexible support for non-PromSlffe 
systems through QS/OS, already evidenced by 
the support of AppleShare and High Sierra file 
systems. 

It isn't difficult to point to other computers 
and fmd chinks in the llgs armor, but taking ali 
things into account at once the llgs fares bet- 
ter. HyperCard on the Mac isn't in color, MS- 
DOS systems have to kludge the use of extend- 
ed memory . neither system has the built-in 
sound capability of the llgs. 

We don't know whether any of the above 
three areas interests you but it's our belief that 
hypermedia and networking capabilities are 
becoming desirable features of computers, and 
that although not everyone wants to be a sys- 
tem programmer, the availability of better lan- 
guages will attract the better programmers 
(most programmers who write GS/OS-based 
software are not anxious to return to the 8-bit 
programming environment).— DJD 
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